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Methods for bridging a HAVi sub-network and a UPnP sub-network and device for 

implementing said methods 

The invention concerns methods to bridge HAVi and UPnP sub-networks, a 
first method addressing the issue of making UPnP objects available to HAVi objects, a 
second method addressing the issue of making HAVi objects available to UPnP 
objects. The invention also concerns a bridge device. 

The invention applies among others to home networks. 

Several sub-networks based on different physical media (wired and wireless) 
and applications are expected to coexist in a digital home network. Common examples 
of wired physical media include the coaxial cable, twisted pair wiring, power line and 
optical fibers. A digital home network also needs to contend with the technological 
developments within the computer, consumer electronics, telephony and home 
automation industries. 

There have been two recent initiatives within the industry to address different 

needs: 

1 . Home Audio-Video interactivity (HAVi) 

2. Universal Plug and Play (UPnP) 

There is a need for harmonization of the two system approaches in order to 
ensure coexistence and interoperability of devices within these domains. The bridging 
of the two technological approaches, is thus desirable. 

The first initiative, Home Audio-Video Interoperability (HAVi), started within 
the consumer industry is an attempt to accomplish high-speed interconnectivity over an 
IEEE 1394 serial bus network for transacting audio/visual data. This initiative was 
specifically intended to address the needs of the consumer electronics devices to 
enable interactivity (with user involvement in a user-device interaction paradigm) and 
interoperability (with no user involvement in a device-device interaction paradigm). 
Further, within HAVi, there is a strong emphasis on enabling streaming applications in 
addition to control applications. An example of a streaming application would be an 
application transferring a video stream from a recording device to a decoder or display, 
while an example of a control application would be an application for programming the 
behavior of devices. This implies a support for both isochronous and asynchronous 
transactions. 
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The other key features of HAVi include: 



1 . Hot Plug and Play 
^ 2. Hardware and Operating System Platform neutrality 

5 3. Support for legacy devices (i.e. devices with no HAVi functionality) and a 

gradual evolution to support new technologies 

The second initiative is Universal Plug and Play (UPnP). While HAVi is 
intended primarily for a high speed IEEE 1394 network for Audio/Video transactions, 
10 UPnP is an initiative that is physical layer agnostic and expects to work on a TCP/IP 
network. The general notions and paradigms are based on the Internet protocols with 
additions to support the notions of plug and play. 



The following non-exhaustive list of documents describe the above 
15 architectures in their current state of development, at the priority date of the present 
application: 



For HAVi: 

The HAVi 1.0 beta* specification, dated October 23, 1998 

20 

The UPnP technology comprises a set of protocols based on TCP/IP: 

- 'Automatically choosing an IP Address in an Ad-Hoc IPv4 Network' (<draft- 
ietf-dhc-ipv4-autoconfig-04.txt>) 

- 'Simple Service Discovery Protocol 1.0' (< http://search.ie.org/intemet- 
25 drafts/draft-cai-ssdp-v1-01 .txt >) 

- 'Multicast Discovery of DNS (Domain Name Server) Services' (<draft- 
manning-multicast-dns-01 .txt>). 

- 'Extended Markup Language' - XML (1.0 W3C recommendation) 



30 More information concerning these two architectures is available on the 

corresponding websites, ie. www.HAVi.org and www.UPnP.org . 

At present, there is no interoperability to ensure that a uniform control 
paradigm, i.e. model, is available so that devices in both the HAVi sub-network and the 
35 UPnP sub-network are able to interact with devices and perform control functions over 
their respective sub-network boundary. 



2 
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The object of the invention is a method for bridging a HAVi sub-network and 
a UPnP sub-network comprising the steps of: 

^ - discovering UPnP devices and/or services on the UPnP sub-network; 

5 - declaration, by a sub-network bridging device, of a discovered UPnP 

device as a HAVi Device Control Module and of a discovered UPnP service as a HAVi 
Functional Component Module on the HAVi sub-network. 

UPnP devices and/or services normally all have HTTP capability. 
According to a variant, only certain UPnP devices or services are declared 
10 on the as HAVI DCMs or FCMs, based on selection criteria. 

According to a preferred embodiment, the discovery step is carried out using 
Simple Service Discovery Protocol (SSDP) functions. 

Another object of the invention is a method for bridging a HAVi sub-network 
15 and a UPnP sub-network comprising the steps of: 

- discovering HAVi software elements of the HAVi sub-network 
corresponding to a selection criterion; 

- representing, in a sub-network bridging device, each of said discovered 
20 elements by a UPnP proxy service identified by a port number attributed by said sub- 
network bridging device; and 

- announcing each of said proxy services on the UPnP sub-network. 

According to a preferred embodiment, the discovery step comprises the step 
25 of requesting, by said sub-network bridging device, a list of software elements from its 
HAVi Registry. 

According to a preferred embodiment of the inventions above, the selection 
criterion is HTTP capability. 
30 HTML capability may be another criterion. 

Another object of the invention is a device for bridging a UPnP sub-network 
and a HAVi sub-network implementing the above method steps. 



35 Other characteristics and advantages of the invention will become apparent 

through the description of a non-limiting, preferred embodiment, described with the help 
of the attached drawings among which: 
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- figure 1, already described, represents a HAVi network and a UPnP 
network linked through a bridge device ; 

- figure 2, already described, represents a single network comprising both 
^ HAVi and UPnP compliant devices ; 

5 - figure 3 represents the networks of figure 1 in which each network 

comprises an HTML browser capable device ; 

- figure 4 is a schematic diagram of protocol stacks in the bridge device, 

- figure 5 is a flowchart of the process carried out to represent a UPnP 
device in the network, 

10 - figure 6 is a flowchart of the process carried out to represent a HAVI device 

in the network. 

In addition to the documents cited in the introduction of the present 
application, one should also refer to the Hypertext Transfer Protocol ('HTTP') 1.1 for 
15 further background information. 

Figure 1 represents an example of a home network composed of a HAVi 
based home sub-network and a UPnP based home sub-network that are bridged 
together. Nodes A and D are displays where the user can view the network topology 

20 and can control, through an appropriate user interface, any node on either network. 
This implies that from node A, the user should for example be able to detect the 
connection of node E to the UPnP network and should be able to control it. In a similar 
manner, a user of node D on the UPnP sub-network should be able to detect the 
appearance of a new HAVi device within the HAVi sub-network and should be able to 

25 control it. 



In Figure 1, the two sub-networks are built over two different media. 
However, the problem to be solved is the same in the situation where both network 
architectures are built over the same media as shown in Figure 2. The nodes A, B and 
30 C are HAVi aware and the nodes C, D and E are UPnP aware. In both configurations, 
there is a node (node C in both examples) which implements the bridge function in 
order to enable the control of any device across the entire network. 

Within the context of the UPnP network, it is necessary to detect the entry of 
35 a new device into the network, announce its capabilities in a well defined manner and 
allow the commencement of interaction with other devices within the network. The 

4 
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SSDP protocol and XML operating over the TCP/IP network are used to accomplish 
this functionality. 

For user control of devices, HTML may be used instead of XML. 

5 As described earlier, HAVi is a complete system solution to the 

interoperability of devices with a IEEE 1394 interface. HAVi addresses, among others, 
the following issues: 

1. Registration of devices and of functions thereof 
10 2. Communication media management (the media being an IEEE 1394 serial 

bus in this case) 

3. Representing devices and functions within devices using device control 
modules ('DCMs') and function control modules ('FCMs'), respectively: 



15 - the list of services provided by a DCM includes connection management, 

status queries for the device and its plugs 

- there is a comprehensive list of FCMs representing the most common 
consumer electronic functional elements 



20 4. Event management (using an event manager) 

5. Stream management (using a stream manager) 

6. Resource management 

7. Support for legacy devices 

8. Data Driven Interaction (DDI) mechanism 



Additions to HAVi compared to UPnP include specific provisions for stream 
management, communication media management and resource management. These 
additions are quite important in the context of an AA/ network based on the IEEE 1394 
30 bus, which imposes severe real time constraints. 



One of the issues regarding the interaction between the HAVi and UPnP 
sub-networks is the need for a common user control protocol. The Data Driven 
Interaction (DDI) protocol, which is standard in HAVI, is not standard within the UPnP 
■35 network. According to the DDI protocol, a controller software element obtains data 
relative to a user interface from a target software element. The controller uses this data 
to build a user interface. HTML on the other hand is standard in an Internet Protocol 
(IP) based computer network (including UPnP), but is not included in HAVI. The 
following functionalities are thus required: 

5 
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- a user control protocol which can be used across the whole network. The 
embodiment uses the HyperText Mark-up Language (HTML) to implement the user 
control protocol. Another protocol with similar functionality may of course be used. 

- a bridge function which will allow : 

(a) connection of the two different discovery protocols 

(b) carrying the user control protocol data over the entire network, HTML 
data in the present case. 

The Hypertext Transfer Protocol (or HTTP) is a request/response protocol. 
The embodiment uses this protocol to accomplish the bridging function mentioned 
earlier. 

The request/response mechanism dictates a client/server model for devices 
using HTTP. Two objects are involved in HTTP : the client, which sends a command, 
and an origin server that receives the command and sends back the response. 

The HTTP protocol has a list of well defined methods (or commands) which 
include the following: 

1 . Option 

2. Get 

3. Head 

4. Post 

5. Put 

6. Delete 

7. Trace 

The most commonly used command is GET < URL> where the Uniform 
Resource Locator (URL) points towards the object to be obtained. This reference is 
composed of two parts : the first points towards the server equipment and the second 
points towards the object associated with the command. This target object can be an 
existing object such as a HTML script or a bit-map or other objects. However the object 
reference can point towards something that has a meaning for the server but does not 
represent any real object. This is used, for instance, in an HTML script to signal to the 
server that the user just selected an icon. After the user selects the icon, the HTML 
script associates this icon with a URL which will be sent to the WEB server (through the 
GET command). A URL reference can thus include some parameters representing a 
command from upper layer protocols. 
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Basically, a user (which can be an application) requires the ability to detect 
the network changes (new or removed devices and/or services). He also requires the 
ability to control devices through a user interface (a well-known language or protocol). 

5 The user control interface model of both networks is first addressed. Then, a 

bridge between other control protocols to operate UPnP and HAVi services over the 
entire network is defined. 

Each network technology specifies a way to dynamically discover the 
10 appearance or the disappearance of services and devices. The first task of the bridge 
function is to connect both discovery methods,through 

- a method to represent and to reach a UPnP device/service for a HAVi 
application within the bridge device; 
15 . a method to represent and to reach a HAVi device/service for a UPnP 

application within the bridge device. 

The UPnP protocol for this discovery function is the Simple Discovery 
Protocol (called SSDP) mentioned in an earlier section. The HAVi protocol for the 
20 corresponding function is the Registry. 

Regarding the bridging of the user control interface we need to map the 
HAVi and the UPnP worlds. HAVi specifies two protocols which are different from the 
user control protocol HTML. 

25 

The present embodiment proposes to define: 

- a user control protocol which can be used across the whole network : 
HTML over HTTP is chosen, since it is already available in one of the sub-networks; 

- a method to implement the chosen user control protocol (HTTP) protocol 
30 within the HAVi paradigm. 

Regarding the bridging of other services (UPnP or HAVi), the embodiment 

includes: 

35 . a method for a HAVi applications to operate the UPnP service/device; 

- a method for a UPnP application to operate the HAVi service/device. 



In Figure 3, the bridge function is included in the device C. Any device, 
irrespective of its functionality, could host the bridge function. The host device 
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comprises the HAVi middleware and the UPnP protocol stack. For clarity purposes, the 
C device according to the present embodiment does not provide any functionality other 
than the bridge as described below. 

5 The next section describes the steps to take into account the following 

scenarios: 

- Scenario 1: the network topology is the same as shown in the Figure 3 
except that the E device is not present. After power on, a user application of A (e.g. an 

1 0 HTML browser) is able to give back to the user the network list of the HTML controllable 
devices. This includes all UPnP sub-network devices and the HTML capable devices of 
the HAVi sub-network. The E device is plugged on to the UPnP network. The User 
application detects this new device (through the ANNOUNCE method of SSDP). The 
user should then be able to control the E device using HTML. 

15 

- Scenario 2: the network topology is the same as shown in the Figure 3 
except that the B device is not present. After power on, the User application of D (the 
HTML browser), is able to give back to the user the network list of the HTML 
controllable devices (discovery by SSDP queries). The B device is plugged on to the 

20 HAVi network. The user application detects this new device (announcement). Then the 
user will be able to control the B device using HTML. 

HTML data is transported using the HTTP protocol. However, HTTP is a 
means to transport any type of hyper text based content. Just as through HTTP we are 

25 able to obtain any User Interface object, such as an icon or a bitmap, we are able to 
transport XML content as well. Today, the most popular Markup language is HTML. 
Consequently many product tools already exist. This is the reason that according to the 
present embodiment, HTML is implemented within the HAVi network. XML is an 
emerging standard, and could be used instead of HTML without any modification to the 

30 embodiment since XML content can also be transported over HTTP . According to a 
variant embodiment, XML and HTML are used jointly. Other protocols may be used as 
well. _ 

The following section describes one implementation of HTTP (HTML) in the 
35 HAVi sub-network. This protocol is a simple command/response protocol between a 
controller and a target (called HTTP server). In HAVi, each device is represented by a 
software component called a DCM (Device Control Module). This DCM contains a 
certain number of well specified entry points (represented by a set of functions) which 
can be used (called) by any other software element of the HAVi network. Like a C- 

8 
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language function, when a software element calls a function of a DCM (whether 
remotely or locally, this being transparent to the caller), an associated process is 
started and the function returns the result of the process. To implement the HTTP 

w# paradigm, a new set of function is added within the DCM Application Programmable 
5 Interface (API) to offer the possibility to handle the HTTP protocol between two HAVi 
software elements - for example between an application (a browser) and a DCM (the 
HTTP server). HAVi uses the IDL (Interface Definition Language) to specify a function. 
Due to the nature of the HTTP protocol, it is possible that HTTP requests or responses 
contain a very large pay load. The transport layer of HAVi specifies a limit on the 

10 message size that can be exchanged between two HAVi software elements. However 
HAVi specifies a way to handle such large messages by a recommended design of the 
API of the element potentially involved in such communications (see APIs for Bulk 
transfer). 

15 The following code illustrates the proposed API extension for the DCMs 

which would implement an HTTP server. 

enum FileLoc {START, MIDDLE, END}; 

20 This parameter permits to indicate whether the message from a producer to 

a consumer is the first message, an intermediate message, or the last message. If the 
stream to be sent fits into one message, the END value will be used. 

(a) The following function allows a software element client (or HTTP client) to 
25 open a HTTP connection with a DCM. 

Status DCM::HttpOpen ( 

in short clientBufferSize, 
in OperationCode opCode, 
out long cid, 

30 out short ServerBufferSize) 

The parameters have the following meaning: 

"clientBufferSize" : indicates the maximum size (in bytes) of a message 
35 accepted by the requester. The DCM will take that parameter into account during the 
sending of the HTTP response to the client. 



9 



WO 00/76131 




PCT/EP00/05026 



"opcode" : this is the operation code the DCM will use to send the HTTP 
response back to the client. The client function identified by this operation code must 
comply with the prototype named <client>::HttpResponse, given below. 

5 "cid" : the identifier of this HTTP connection with the DCM. It allows several 

connections from the same software element client and also permits to match a 
response with a request. 



"ServerBufferSize" : indicates the maximum size (in bytes) of a message 
10 accepted by the DCM. The HTTP client will take this parameter into account during the 
sending of the HTTP requests. 

The error codes for this function are the following: 

"DCM::ENUM_CONN H : maximum number of opened connections is reached 
15 for this DCM 

"DCM::EALLOC": resource allocation error 



(b) A second function is used to allow a software element client to close a 
HTTP connection: 

20 

Status DCM::HttpClose (in long cid) 



The parameter "cid" is the identifier of this HTTP connection with the DCM. 
This function is used to close a connection with a Web proxy FCM. The error code is 
25 the following: 

"DCM::ECID": The cid is unknown. 



(c) A third function allows a software element client (or HTTP client) to send 
a request to a DCM acting as a HTTP server according to HTTP. 

30 

Status DCM::HttpRequest ( 
in long cid, 
in FileLoc where, 
in sequence<octet> data) 

35 

Parameters 



"cid": the identifier of the connection between the HTTP client and the DCM 
(acting as a HTTP server) obtains by the HTTP client from a DCM::HttpOpen call. 

10 
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"where": informs the DCM that this message is the first, the last or an 
intermediate message of the request. 

5 "data": contains a part or the entire request according to the HTTP protocol. 

Error codes: 

"DCM::ESIZE M : the data exceeds the size of the buffer in the receiver. The 
10 receiver has not received or processed the data. It is left to the implementation how the 
sender reacts to this status error. 

"DCM::EFAILED": the receiver has aborted the transfer of the current 
sequence of data transfers. The sender shall abort the transfer of the current sequence. 

"DCM::ECID M : The "cid" is unknown. 

15 

(d) The fourth function to be implemented in the client allows the DCM 
(acting as HTTP server) to send back to the client a HTTP response corresponding to a 
previously received HTTP request from that client through the connection identified by 
"cid": 

20 

Status <Client>::HttpResponse( 
in long cid, 
in FileLoc where, 
in sequence<octet> data) 

25 

"cid": the identifier of the connection between the HTTP client and the DCM . 

"where": informs the client that this message is the first, the last or an 
intermediate message of the response . 

30 

"webData": contains a part or the entire response according to the HTTP 
protocol used through the connection identified by the "cid" parameter. 

This is the prototype of the function to be implemented in the client which 
allows the DCM (acting as a HTTP server) to give back to the client a HTTP response 
35 corresponding to a previously received HTTP request from that client through the 
connection identified by "cid". 

The error codes are the followings: 



11 



WO 00/76131 PCT/EP00/05026 



,r WebProxy::ESIZE ,, : the data exceeds the size of the buffer in the receiver. 
The receiver has not received or processed the data. It is left to the implementation how 
the sender reacts to this status. 

"WebProxy::EFAILED H : the receiver has aborted the transfer of the current 
sequence of data transfers. The sender shall abort the transfer of the current sequence. 

"WebProxy::ECID": The cid is unknown. 



In HAVi, the designer of a target device can decide which user control 
protocol to implement, among the two protocols currently defined by HAVi. It is not 
required to provide user control capabilities as specified in HAVi. For the controller 
application, it is necessary to know whether a particular target is user-controllable or 
not. This is the goal of an attribute in the HAVi Registry. The Registry is a database 
where all software elements of a device are registered (including DCMs and application 
modules). Any software element can query the database. Each time an element is 
added or removed, a corresponding network event is generated. In the Registry, an 
element is registered with a set of attributes which characterize it. One of these 
attributes is the GUIREQ attribute, which defines whether this element can be 
controlled through a user control protocol and if yes, through which protocol. The 
possible values for the attribute are : 

• NO_NEED 

• DDI (the basic Ul protocol in HAVi) 

• HAVLET (the Java based Ul protocol in HAVi) 

The invention proposes to add a new value of this attribute: 

• HTTP (the HTTP/HTML paradigm in HAVi) 

When a user wants to control a device, its associated client application, 
typically an HTML browser, displays the set of network devices which are HTTP/HTML 
capable by querying the Registry on the corresponding GUIREQ attribute value. The 
user selects one of these and the client application can send the HTTP GET command 
towards the DCM of the selected target, according to that protocol. To send the HTTP 
command, the client application first establishes an HTTP connection with the target 
DCM (calling the "DCM::HttpOpen" method) and then performs one or several calls 
(depending on the size of the request and the capabilities of the target DCM in term of 
the HAVi message size) to the DCM. The DCM then uses the "DCM: HttpRequest" to 
send its HTTP request. Once the target receives the command, it sends back the Home 
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HTML page associated with the device to the client by calling one or more times the 
client method called "HttpResponse". The client application (the browser) then 
interprets the HTML script and displays the corresponding User Interface. 

The bridge function is implemented in a device (called the bridge device or 
simply the bridge) which is connected to both sub-networks as shown in Figure 3 
(device C). Thus it has to contain, at least, the protocol stack as shown in the Figure 4. 
Since the SSDP protocol requires some multicast capabilities, the IP layer will be IGMP 
('Internet Group Management Protocol') compliant. 

The method of modelization of a UPnP device or service by the bridge seen 
from the HAVi sub-network will now be described. 

The UPnP network is composed of devices that offer access to some 
network services. The SSDP protocol permits the discovery of the services available in 
the network and indirectly the device that hosts the service. The HAVi network is 
composed of devices that contain one or more functional components (equivalent to 
services in UPnP). As already mentioned, a DCM is used to represent a device, and an 
FCM is used to represent a functional component. In HAVi, the User control protocol is 
managed through the DCM API. 

According to the invention: 

- A UPnP device is represented by a DCM in the bridge device. 

- This DCM contains the extra API for HTTP. 

- A UPnP service (except for the HTTP service) will be represented by a 
FCM in the bridge device. 

It is mandatory to register these DCMs and FCMs through the HAVi 
REGISTRY service to allow any other HAVi object to discover them and, thus, to be 
able to operate them. The registration consists in registering the HAVi addresses of 
these software elements and the mandatory attributes according to the HAVi 
specification: - 

- Type of software element (either DCM or GENERIC FCM) 

- HUID (unique hardware identifier : computed by the bridge device) 

- Device class (LAV - meaning Legacy device) 

- GUIReq (HTTP) 

- DeviceManufacturer (manufacturer of the UPnP device/service) 
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- SoftwareElementVersion (computed by the bridge device) 

- UserPreferredName (computed by the bridge device - based on the UPnP 
service/device name) 

Before the bridge device is able to activate and register a DCM/FCM 
corresponding to a UPnP device/service, it has to detect its presence within the UPnP 
sub-network. 

According to the SSDP (Simple Service Discovery Protocol) of UPnP, the 
bridge device acts as a SSDP client and server. Once the bridge device is connected to 
the home network, its SSDP client has to query the UPnP sub-network by sending the 
multicast "OPTIONS" message over UDP/IP to query the SSDP servers. The SSDP 
"OPTIONS" message will have the following format according to the HTTP 
specification: 

OPTIONS J_ HTTP/1 .1 Request-ID: uuid:1313Att-Locations: 
<httpu://bridge.com/bar:1 1 1 1> 

This message contains the type of services concerned by the query ("_*_" 
meaning : all), the version number of HTTP, a unique identifier to match the response 
with the query (the value shall respect a format described in the RFC 2518), and the 
URL the responder will use to give back its response(s) (the port number 1111 
correspond to the SSDP client of the bridge). 

All UPnP devices will send back one or several SSDP OPTIONS responses 
(one by service implemented within the device) containing the name of the service, the 
network location of the service (the URL used to reach the service), the protocol to be 
used to communicate with the service and a set of data to describe the device which 
hosts the service according to the following : 

- Device manufacturer name 

- Device name 

- A URL to obtain an icon representing the device 
The bridge device parses all responses and: 

- For each new device detected, it installs and declares a HAVi DCM and 
registers it in its local Registry with its well specified attributes as described earlier. 

- For each new service type, for which the bridge wants to offer the access to 
the HAVi network, it installs and declares a HAVi FCM and also registers it with its well 
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specified attributes as described earlier. Other attributes than those indicated above 
may also be registered. 

Consequently the DCM t respectively the FCM shall maintain a set of 
configuration data to be able to identify and join its associated UPnP device, 
respectively service. 

For the DCM: 

- The URL to join the HTTP server of the UPnP device (if this service is 
implemented in the device) 

- The Device manufacturer name 

- The Device name 

- The URL to get an icon representing the device 
For the FCM: 

- The URL to join the UPnP service 

- The type of the UPnP service (printer for example) 

- The Device manufacturer name of the UPnP host device 

- The service name of the UPnP service (PrinterRoom2 for example) 

- The URL to get an icon representing the device 

When a UPnP device is plugged into the network, it has to send the SSDP 
ANNOUNCE message containing the name of the network service it provides, the 
network location and protocol to be used to communicate with it. The SSDP server of 
the bridge is listening to the well-known multicast port number. Thus for each incoming 
ANNOUNCE message, the bridge device will parse the message according to the 
manner described below. 

The process for integrating a UPnP device into the network is illustrated by 
the flowchart of figure 5. 

For each detected UPnP device/service, the bridge device installs a 
DCM/FCM to control this UPnP device/service as explained in the previous sections. 
The HAVi sub-network has the knowledge of these new elements. Any application in 
the HAVi sub-network can then control a UPnP target. In our example (cf Figure 3) the 
A device provides the user on its display with the list of devices in its home network 
represented by icons. To realize that, the user application of A (an HTML browser) has 
previously queried the HAVi registry to obtain all the identifiers of DCMs which offer an 
HTTP API. 
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The user would like to control the E device using HTML and selects its 
associated icon. The user application in A establishes the HTTP connection with the 
associated DCM. The User application then sends the HTTP request to the DCM calling 
the function DCM::HttpRequest. The DCM then establishes the TCP connection 
according to HTTP between the bridge device (C) and the UPnP target (E) and 
forwards the HTTP request. To establish the connection, the DCM will use the URL 
associated with the HTTP server service of the UPnP target previously registered as 
configuration data. 

Once the HTTP command (the HTTP_GET command for instance) is 
received by the UPnP target, it sends back the response (an HTML page) to the DCM 
which will forward this response to the source of the request. 

The moderation of a HAVi target seen from the UPnP sub-network will now 
be described. The process for integrating a HAVi device into the network is illustrated 
by the flowchart of figure 6. 

The UPnP model is based on the TCP/UDP/IP protocols. Consequently, a 
UPnP device is a network entity which can be reached through its IP (Internet Protocol) 
address. A service is an entity within the application layer (over TCP or UDP) which can 
be reached through a port number. The port number identifies the connection path 
between two UPnP entities (an application and a service for example). To represent a 
HAVi device or a HAVi functional component within the bridge we basically have two 
solutions: 

- The first solution is based on port numbers and is used for the rest of the 
description, as explained below. 

- The second solution is based on multiple IP addresses: local IP addresses 
are assigned to each device or functional component within the HAVi network. This 
assignment can be made to be consistent with the SSDP mechanism. The invoked 
HAVi component (either a DCM or an FCM) can, on instantiation, request a unique IP 
address assignment from the bridge just as any other UPnP device entering the UPnP 
network. 

The notion of a 'device 1 in UPnP is used only to reach the network entity and 
to obtain data describing the location where the service resides. Consequently there is 
no need to represent a HAVi device as a UPnP device. What is needed it to represent 
some HAVi services as the HAVi functional component APIs (FCM) and the HTTP API 
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(offered by the DCM). According to the present embodiment, the so-called port number 
solution consists in representing a HAVi service by a proxy UPnP service (like a HTTP 
proxy server) where each proxy is associated with a port number (either TCP or UDP) 
attributed by the bridge. 

UPnP requires that for any new services the SSDP client of the hosted 
device announce the service list it owns. The bridge uses the HAVi REGISTRY to be 
able to query or detect the new HAVi targets as FCM or DCM according to the 
appropriate criteria, which is, according to the present embodiment, the GUIREQ value. 

Consequently, once the bridge detects a HAVi target (either a DCM or a 
FCM) for which a proxy UPnP service can be activated, it generates the SSDP 
multicast ANNOUNCE message to the UPnP subnetwork. The following ANNOUNCE 
message is used to announce a HTTP server service represented by a HTTP proxy 
within the bridge device: 

ANNOUNCE server:HTTP HTTP/1.1 Location: httpu://bridge.com:123 

The URL "server: HTTP" is the type of the service. The location field contains 
the URL to reach the service. It is composed of the address of the bridge device and a 
port number chosen by the bridge device and dedicated to the HTTP proxy associated 
with the HAVi target. 

Each time a new proxy has to be activated, the bridge device chooses a new 
(private) port number related to the transport protocol used to reach that service (either 
UDP or TCP). 

The entity body of the ANNOUNCE message will contain the following fields 
which help to identify the device hosting the service: 

- Device manufacturer name 

- Device name 

- A URL to obtain an icon representing the device 

It is possible also that the SSDP server of the bridge device receives an 
OPTIONS message from any UPnP device. The bridge will have to respond according 
to the description presented earlier. 

Consequently the proxy service shall maintain a set of configuration data to 
be able to identify and join its associated HAVi target (either a DCM or a FCM). This 
configuration data shall comprise the Software Element Identifier (SEID) of the HAVi 
target. 
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Once a proxy is installed and declared to the UPnP sub-network, any 
application in the UPnP sub-network can then control these HAVi targets. In our 
example (cf Figure 3) the device D provides to the user the list of devices in its home 
. 5 network represented by icons. To realize that, the user application of device D (a HTML 
browser) has previously queried the UPnP sub-network through the SSDP OPTIONS 
method to get the description of all devices which implement a HTTP server service. 

The user would like to control the device B using HTML and selects its 
10 associated icon. The user application in device D establishes the TCP connection with 
the HTTP proxy -associated with the HAVi target device B - embedded in the bridge 
device. The HTTP proxy then establishes a HTTP connection with the DCM 
representing the HAVi target calling the DCM::HttpOpen method as described earlier. 
The User application then sends the HTTP request to the HTTP proxy through the TCP 
15 connection. The HTTP proxy then forwards the HTTP request to the HAVi target device 
B (in fact its DCM) by calling the function DCM::HttpRequest. The DCM then sends 
back the HTTP response (its HTML home page for instance) by calling the HTTP proxy 
(method <client>::HttpResponse ) acting as the HTTP client within the HAVi sub- 
network. The HTTP proxy will then forward the response to the user application located 
20 in device D. 

Although the preferred embodiment concerns the interoperability of a UPnP 
sub-network and of a HAVi sub-network, the invention is not limited to these two 
network types and may also be applied to other types of networks. 

25 
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Claims 



1. Method for bridging a HAVi sub-network and a UPnP sub-network 
.5 comprising the steps of: 

- discovering UPnP devices and/or services on the UPnP sub-network; 

- declaration, by a sub-network bridging device, of a discovered UPnP 
device as a HAVi Device Control Module and of a discovered UPnP service as a HAVi 

10 Functional Component Module on the HAVi sub-network. 

2. Method according to claim 1, wherein the step of declaring a Device 
Control Module and Functional Component Module comprises the step of registering in 
a Registry of the bridging device. 

15 

3. Method according to claim 1, wherein the discovery step is carried out 
using Simple Service Discovery Protocol (SSDP) functions. 

4. Method for bridging a HAVi sub-network and a UPnP sub-network 
20 comprising the steps of: 

- discovering HAVi software elements of the HAVi sub-network 
corresponding to a selection criterion; 

- representing, in a sub-network bridging device, each of said discovered 
25 elements by a UPnP proxy service identified by a port number attributed by said sub- 
network bridging device; and 

- announcing each of said proxy services on the UPnP sub-network. 

5. Method according to claim 3, wherein the discovery step comprises the 
30 step of requesting, by said sub-network bridging device, a list of software elements from 

its HAVi Registry. 

6. Method according to claims 3 or 4, wherein the step of announcing a 
proxy service comprises transmission of a bridging device address and proxy service 

35 port number. 

7. Method according to one of the claims 3 to 6, wherein the bridging 
device maintains a set of configuration data for each proxy service, identifying an 
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associated HAVi software element, said data comprising the software element's 
identifier. 

8. Method according to one of the preceding claims, wherein the selection 
criterion is HTTP capability. 
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(Any replacement sheet containing such amendments must be referred to under item 1 and annexed to this 
report.) 



6. Additional observations, if necessary: 



IV. Lack of unity of invention 

1 . In response to the invitation to restrict or pay additional fees the applicant has: 

□ restricted the claims. 

□ paid additional fees. 

□ paid additional fees under protest. 

□ neither restricted nor paid additional fees. 

2. □ This Authority found that the requirement of unity of invention is not complied and chose, according to Rule 

68.1 , not to invite the applicant to restrict or pay additional fees. 

3. This Authority considers that the requirement of unity of invention in accordance with Rules 13.1, 13.2 and 13.3 is 

□ complied with. 

IS not complied with for the following reasons: 
see separate sheet 

4. Consequently, the following parts of the international application were the subject of international preliminary 
examination in establishing this report: 

□ all parts. 

H the parts relating to claims Nos. 1-3. 



V. Reasoned statement under Article 35(2) with regard to novelty, inventive step or industrial applicability; 
citations and explanations supporting such statement 

1. Statement 



Novelty (N) 
Inventive step (IS) 



Yes: Claims 1 -3 

No: Claims 

Yes: Claims 1-3 

No: Claims 
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Industrial applicability (IA) Yes: Claims 1-3 

No: Claims 



2. Citations and explanations 
see separate sheet 



VII. Certain defects in the international application 

The following defects in the form or contents of the international application have been noted: 
see separate sheet 



VIII. Certain observations on the international application 

The following observations on the clarity of the claims, description, and drawings or on the question whether the 
claims are fully supported by the description, are made: 
see separate sheet 
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IV. Lack of unity of invention 

1 . The International Preliminary Examining Authority found multiple (groups of) 
inventions in this international application, which are the following: 

I. Claims 1-3: 

A method addressing the issue of making UPnP objects available to HAVi objects. 

II. Claims 4-8: 

A method addressing the issue of making HAVi objects available to UPnP objects. 



2. Therefore, two groups of claims are not linked by common or corresponding 

special technical features and define two different inventions not linked by a single 
general inventive concept. The application, hence does not meet the requirements 
of Unity of Invention as defined in Rules 13(1)&(2) PCT. 



V.Reasoned statement under Rule 66.2(a)(ii) with regard to novelty, inventive 
step and industrial applicability; citations and explanations supporting such 
statement 

I 

The following documents have been considered for the purposes of this report: 
D1: EP-A-0 849 913 

D2: DESBONNETJ ET AL: 'SYSTEM ARCHITECTURE AND 

IMPLEMENTATION OF A CEBUS/INTERNET GATEWAY' IEEE 
TRANSACTIONS ON CONSUMER ELECTRONICS.USJEEE INC. NEW 
YORK, vol. 43, no. 4, 1 November 1997 (1997-11-01), pages 1057-1062 

D3: CHILD J: 'INTELLIGENT HOME TECHNOLOGY LOOKS FOR LEVERAGE 
FROM RELATED MARKETS' COMPUTER DESIGN, US,PENNWELL PUBL 
LITTLETON, MASSACHUSETTS, vol. 36, no. 12, 1 December 1997 (1997- 
12-01), pages 85-87 
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D4: SONY PHILIPS HITACHI SHARP MATSUSHITA THOMSON TOSHIBA 
GRUNDIG: Specification of the Home Audio/Video Interorperability 
Architecture' HAVI ARCHITECTURE,XX,XX, 1 1 May 1998 (1998-05-1 1), 
pages 25-29 



II 

The invention concerns a method to bridge HAVi and UPnP sub-networks, addressing 
the issue of making UPnP objects available to HAVi objects. 

Document D1 discloses a data communication system comprising an IEEE-1394 serial 
bus to which are connected several domestic devices. It does not mention any 
possibility of making UPnP objects available to HAVi objects. D1 is therefore 
considered as defining the general state of the art and not particularly relevant. 

Document D2 specifies a system architecture and implementation of a CEBus/internet 
gateway. D2 is therefore also considered as defining the general state of the art and 
not particularly relevant for the same reasons as D1 . 

Document D3 describes an overview of bus standards for controlling smart-home 
systems including X-10, CEBus and LonWorks. D3 can therefore also be considered as 
defining the general state of the art and not particularly relevant for the same reasons 
as D1. 

Document D4 is a specification of the Home Audio/Video Interoperability (HAVi) 
Architecture. D4 can therefore also be considered as defining the general state of the 
art and not particularly relevant for the same reasons as D1. 

An inventive step is therefore acknowledged and claims 1 to 3 fulfill the requirements of 
Article 33(3) PCT. 
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VII. Certain defects in the international application 

1 . The independent claims are not properly casted in the two-part form, with those 
features which in combination are part of the prior art, being placed in the 
preamble (see Rule 6.3(b) PCT). 

2. Documents D1-D4 are not identified in the description and the relevant 
background art disclosed therein is not be briefly discussed (Rule 5.1 (a)(ii) PCT). 

3. Reference signs in parentheses are not inserted in the claims to increase their 
intelligibility, Rule 6.2(b) PCT. This applies to both the preamble and 
characterising portion. 

4. The description is not brought into conformity with the new claims (see Rule 
5.1(a)(iii) PCT). 

5. Some clerical errors are not corrected in the application : 

- on page 1 , line 8, on page 3, lines 31-32 in the abstract line 23, it is 
mentionned that the invention concerns also a bridge device, which is in 
contradiction with the fact that there are no device claims and only methods 
to bridge HAVi and UPnP sub-networks. 

- "already described" should be deleted on page 4, lines 1 and 3. 



VIII. Certain observations on the international application 

1a. The various definitions of the invention given in independent method claims 1 and 
4 are such that the claims as a whole are not clear and concise, contrary to Article 
6 PCT. The claims are not recasted to include only the minimum necessary 
number of independent claims in any one category (Rule 6.4(a)-(c) PCT). 

1 b. This opinion is also corroborated by the fact that there is a lack of unity between 
claim 1 and claim 4 and the number of claims should have been reduced also for 
this reason (see section IV). 
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2. Method Claim 1 does not meet the requirements of Article 6 PCT for lack of 
clarity. Apart from the fact that the term "discovering" is obscure and not 
technical, the present formulation of claim 1 seeks to replace essential features by 
referring to features which concern the effect which it is desired to achieve. 

The vague formulation "discovering UPnP devices and/or services on the UPnP 
sub-network" is essentially equivalent to a formulation of the type "having an 
action on UPnP sub-network in order to be able to discover UPnP devices and/or 
services" and is in this case not sufficient to clearly define the invention (Article 6 
PCT and PCT Guidelines C-lll, 4.7). 

The technical features which allow UPnP devices and/or services to be discovered 
on the UPnP sub-network do not appear in the method claim 1 as described in the 
description from page 15, lines 19 to line 34. Therefore, claim 1 does not contain 
these essential features, it does not meet the requirements following from Article 6 
PCT taken in combination with Rule 6(3)(b) PCT that any independent claim must 
contain all the technical features essential to the invention. 

3. Abbreviations are used in the claims without having been defined beforehand in 
the claim in the non-abbreviated definition. In this respect, it has to be notified that 
the meaning of the abbreviations "HAVi" and "UPnP" has not been defined. 
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II 
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Priority 
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IV 




Lack of unity of invention 
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Reasoned statement under Article 35(2) with regard to novelty, inventive step or Industrial applicability; 
citations and explanations su porting such statement 


VI 
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Certain defects in the international application 


VIII 




Certain observations on the international application 





Date of submission of the demand 
19/12/2000 1/ 


Date of completion of this report 
31.07.2001 


Name and mailing address of the international 
preliminary examining authority: 

^ European Patent Office 
fijXi O60298 Munich 

Tel. +49 89 2399 - 0 Tx: 523656 epmu d 
Fax:449 892399-4465 


Authorized officer >2S3SS^ 

Droneau.S f J 

Telephone No. +49 89 2399 7954 



INTERNATIONAL PRELII 
EXAMINATION REPORT 




RY 



International 




No. PCT/EP00/05026 



L Basis of the report 

1 . With regard to the elements of the international application (Replacement sheets which have been furnished to 
the receiving Office in response to an invitation under Article 14 are referred to in this report as "originally filed 0 
and are not annexed to this report since they do not contain amendments (Rules 70. 16 and 70. 1 7)): 
Description, pages: 

1-18 as originally filed 



2. With regard to the language, all the elements marked above were available or furnished to this Authority in the 
language in which the international application was filed, unless otherwise indicated under this item. 

These elements were available or furnished to this Authority in the following language: , which is: 

□ the language of a translation furnished for the purposes of the International search (under Rule 23.1 (b)). 

□ the language of publication of the international application (under Rule 48.3(b)). 

□ the language of a translation furnished for the purposes of international preliminary examination (under Rule 
55.2 and/or 55.3). 

3. With regard to any nucleotide and/or amino acid sequence disclosed in the international application, the 
international preliminary examination was carried out on the basis of the sequence listing: 

□ contained in the international application In written form. 

□ filed together with the international application in computer readable form. 

□ furnished subsequently to this Authority in written form. 

□ furnished subsequently to this Authority in computer readable form. 

□ The statement that the subsequently furnished written sequence listing does not go beyond the disclosure in 
the international application as filed has been furnished. 

□ The statement that the information recorded in computer readable form is identical to the written sequence 
listing has been furnished. 

4. The amendments have resulted in the cancellation of: 



Claims, No.: 



1-8 



as originally filed 



Drawings, sheets: 



1/4-4/4 



as originally filed 



□ the description, 

□ the claims, 



pages: 
Nos.: 



INTERNATIONAL PRELIMJflLRY 
EXAMINATION REPORT W 



International 3|PPfcation No. PCT/EPOO/05026 



□ the drawings, sheets: 

5. □ This report has been established as if (some of) the amendments had not been made, since they have been 
considered to go beyond the disclosure as filed (Rule 70.2(c)): 

(Any replacement sheet containing such amendments must be referred to under item 1 and annexed to this 
report) 



6. Additional observations, if necessary: 



IV. Lack of unity of invention 

1 . in response to the invitation to restrict or pay additional fees the applicant has: 

□ restricted the claims. 

□ paid additional fees. 

□ paid additional fees under protest 

□ neither restricted nor paid additional fees. 

2. □ This Authority found that the requirement of unity of invention is not complied and chose, according to Rule 

68.1, not to invite the applicant to restrict or pay additional fees, 

3. This Authority considers that the requirement of unity of invention in accordance with Rules 1 3.1 , 13.2 and 13.3 is 

□ complied with. 

B not complied with for the following reasons: 
see separate sheet 

4. Consequently, the following parts of the international application were the subject of international preliminary 
examination in establishing this report: 

□ all parts. 

EI the parts relating to claims Nos. 1-3. 

V. Reasoned statement under Article 35(2) with regard to novelty, inventive step or Industrial applicability; 
citations and explanations supporting such statement 

1. Statement 

Novelty (N) Yes: Claims 1-3 

No: Claims 



Inventive step (IS) Yes: Claims 1-3 

No: Claims 
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Industrial applicability (IA) Yes: Claims 1-3 

No: Claims 



2. Citations and explanations 
see separate sheet 



VII. Certain defects In the International application 

The following defects in the form or contents of the international application have been noted: 
see separate sheet 



VIII. Certain observations on the international application 

The following observations on the clarity of the claims, description, and drawings or on the question whether the 
claims are fully supported by the description, are made: 
see separate sheet 



ELflfeNARY International application: 

rIKeparate sheet ~ 
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IV. Lack of unity of invention 

1 . The International Preliminary Examining Authority found multiple (groups of) 
inventions in this international application, which are the following: 

I. Claims 1-3: 

A method addressing the issue of making UPnP objects available to HAVi objects. 

II. Claims 4-8: 

A method addressing the issue of making HAVi objects available to UPnP objects. 



2. Therefore, two groups of claims are not linked by common or corresponding 

special technical features and define two different inventions not linked by a single 
general Inventive concept. The application, hence does not meet the requirements 
of Unity of Invention as defined in Rules 13(1)&(2) PCT. 



V.Reasoned statement under Rule 66.2(a)(ii) with regard to novelty, inventive 
step and industrial applicability; citations and explanations supporting such 
statement 

I 

The following documents have been considered for the purposes of this report: 
D1: EP-A-0 849 913 

D2: DESBONNET J ET AL: 'SYSTEM ARCHITECTURE AND 

IMPLEMENTATION OF A CEBUS/INTERNET GATEWAY' IEEE 
TRANSACTIONS ON CONSUMER ELECTRONICS.US.IEEE INC. NEW 
YORK, vol. 43, no. 4, 1 November 1997 (1997-11-01), pages 1057-1062 

D3: CHILD J: 'INTELLIGENT HOME TECHNOLOGY LOOKS FOR LEVERAGE 
FROM RELATED MARKETS' COMPUTER DESIGN.US.PENNWELL PUBL. 
LITTLETON, MASSACHUSETTS, vol. 36, no. 12, 1 December 1997 (1997- 
12-01), pages 85-87 
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D4: SONY PHILIPS HITACHI SHARP MATSUSHITA THOMSON TOSHIBA 
GRUNDIG: 'Specification of the Home Audio/Video Interorperabilrty 
Architecture' HAVI ARCHITECTURE,XX,XX, 1 1 May 1998 (1998-05-1 1), 
pages 25-29 



II 

The invention concerns a method to bridge HAVi and UPnP sub-networks, addressing 
the issue of making UPnP objects available to HAVi objects. 

Document D1 discloses a data communication system comprising an IEEE-1394 serial 
bus to which are connected several domestic devices. It does not mention any 
possibility of making UPnP objects available to HAVi objects, D1 is therefore 
considered as defining the general state of the art and not particularly relevant. 

Document D2 specifies a system architecture and implementation of a CEBus/intemet 
gateway. D2 is therefore also considered as defining the general state of the art and 
not particularly relevant for the same reasons as D1 . 

Document D3 describes an overview of bus standards for controlling smart-home 
systems including X-10, CEBus and LonWorks. D3 can therefore also be considered as 
defining the general state of the art and not particularly relevant for the same reasons 
as D1. 

Document D4 is a specification of the Home Audio/Video Interoperability (HAVi) 
Architecture. D4 can therefore also be considered as defining the general state of the 
art and not particularly relevant for the same reasons as D1 , 

An inventive step is therefore acknowledged and claims 1 to 3 fulfill the requirements of 
Article 33(3) PCT. 
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VII. Certain defects in the international application 

1 . The independent claims are not properly casted in the two-part form, with those 
features which in combination are part of the prior art, being placed in the 
preamble (see Rule 6.3(b) PCT). 

2. Documents D1-D4 are not identified in the description and the relevant 
background art disclosed therein is not be briefly discussed (Rule 5,1(a)(ii) PCT). 

3. Reference signs in parentheses are not inserted in the claims to increase their 
intelligibility, Rule 6.2(b) PCT. This applies to both the preamble and 
characterising portion. 

4. The description is not brought into conformity with the new claims (see Rule 
5.1(a)(iii) PCT). 

5. Some clerical errors are not corrected in the application : 

- on page 1 , line 8, on page 3, lines 31-32 in the abstract line 23, it is 
mentionned that the invention concerns also a bridge device, which is in 
contradiction with the fact that there are no device claims and only methods 
to bridge HAVi and UPnP sub-networks. 

- "already described" should be deleted on page 4, lines 1 and 3. 



VIII. Certain observations on the international application 

la. The various definitions of the invention given in independent method claims 1 and 
4 are such that the claims as a whole are not clear and concise, contrary to Article 
6 PCT, The claims are not recasted to include only the minimum necessary 
number of independent claims in any one category (Rule 6.4(a)-(c) PCT). 

1 b. This opinion is also corroborated by the fact that there is a lack of unity between 
claim 1 and claim 4 and the number of claims should have been reduced also for 
this reason (see section IV). 
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2. Method Claim 1 does not meet the requirements of Article 6 PCT for lack of 
clarity. Apart from the fact that the term "discovering" is obscure and not 
technical, the present formulation of claim 1 seeks to replace essential features by 
referring to features which concern the effect which it is desired to achieve. 

The vague formulation "discovering UPnP devices and/or services on the UPnP 
sub-network" is essentially equivalent to a formulation of the type "having an 
action on UPnP sub-network in order to be able to discover UPnP devices and/or 
services 0 and is in this case not sufficient to clearly define the invention (Article 6 
PCT and PCT Guidelines C-lll, 4.7). 

The technical features which allow UPnP devices and/or services to be discovered 
on the UPnP sub-network do not appear in the method claim 1 as described in the 
description from page 15, lines 19 to line 34. Therefore, claim 1 does not contain 
these essential features, it does not meet the requirements following from Article 6 
PCT taken in combination with Rule 6(3)(b) PCT that any independent claim must 
contain all the technical features essential to the invention. 



3. 



Abbreviations are used in the claims without having been defined beforehand in 
the claim in the non-abbreviated definition. In this respect, it has to be notified that 
the meaning of the abbreviations "HAVi" and "UPnP" has not been defined. 



